Since only persist and scratch buffers are allocated during entablishment phase, we could be only responsible for releasing them during the destruction phase:

static void destroy_instance(struct processing_module *mod)
{
	struct sof_dax *dax_ctx = module_get_private_data(mod);

	dax_free(dax_ctx);
	dax_buffer_release(mod, &dax_ctx->persist_buffer);
	dax_buffer_release(mod, &dax_ctx->scratch_buffer);
}

if sof_dax_reset can always be called before sof_dax_free phase, destruction may be not necessary here.

Theoretically yes, but I don't feel we should rely on that assumption.

The memory free() function of C causes no harm if the input pointer is null. Your dax_buffer_release() implementation is handled well so they are good to be called more than once.

My only concern is that I am not sure if calling dax_free() twice is also good because this is a private call

if so, following releases are also required here:

dax_buffer_release(mod, &dax_ctx->tuning_file_buffer);
dax_buffer_release(mod, &dax_ctx->input_buffer);
dax_buffer_release(mod, &dax_ctx->output_buffer);

dax_free() is safe for multiple frees.

It might be better to place establish_instance after check_media_format to avoid unnecessary destruction if check_media_format fails.
On the other side, we need to add the option CONFIG_IDC_TIMEOUT_US=50000 to the file app/overlays/[ptl/mtl]/dax_overlay.conf to avoid IPC_TIMEOUT errors， because dax_init takes more than 20 ms, exceeding default IDC_TIMEOUT value (10ms).

That's also I worried about. But I don't get why dax_init() takes so long because at that moment DAX didn't even get the configuration data (from dax_param.bin). Or does DAX make the advance calculation on dax_init() such as configuration prediction?

We have verified without changing CONFIG_IDC_TIMEOUT_US and didn't get timeout problem (I assume the timeout should lead to a stable failure if it really cares). Could you check with that?

You can set DOLBY_DAX_CORE_ID as 1 (or other different cores with pipeline) to trigger IDC timer.
dax_init will perform a large number of initialization operations based on the provided memory and load some static data.

I see. You are correct "IDC" is for the inter-CPU communication.

As for dax_init(), do you mean "loading static data" to memory allocated on runtime for speeding the later computation? I remember we didn't use DRAM for ADSP in the current device so it still sounds weird to me.

my bad for clarifying this.This refers to loading static data from RAM (decalared as static arrays and stored in .data section) into runtime buffer and performing initializations for features in it.

@johnylin76 have you looked at putting all instance shared objects in BSS, DATA and RODATA sections and managing in the module wrapper. e.g.

struct instance_shared_data {
    int this;
    void *that;
};

/* shared instance data for all dax modules*/
static struct instance_shared_data *data;  /* will be in module BSS that will be shared with all instances */
static atomic_t instance_count = 0;

int dax_init()
{
    /* check number of instances and create shared data if needed */
   if (atomic_add(instance_count, 1) == 1) {
       /* create the data */
   }

  /* rest of init */
}

void dax_destroy()
{
    /* check instance count and free shared data if last user */
}

The IPC logic enforces locking and serialization so a reference count would allow managing any shared data between dax instances since they are mutually exclusive.

I also assume both dax instances will run on same core ?

Simultaneously release following buffers here:

dax_buffer_release(mod, &dax_ctx->tuning_file_buffer);
dax_buffer_release(mod, &dax_ctx->input_buffer);
dax_buffer_release(mod, &dax_ctx->output_buffer);

Becasue these buffers are also allocated in sof_dax_prepare. If a lifecycle of dax instance is from prepare to reset phrase, then I believe that all resources created in sof_dax_prepare should have the same lifecycle.

Yes. The better practice is releasing all runtime buffers when reset.

tuning_file_buffer should not be released by destroy_instance (or implements a way to recover the buffer data on establishment). Move to sof_dax_free